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SUMMARY 


The research described in this report is presented in 2 parts. 

Part Is Interval Logic for the Verification of Real Time Systems presents a technique for 
the formal expression of the real-time constraints that are critical to the specification 
of fault- tolerant distributed systems. 

Part IIs Extending Interval Logic to Include Processes describes how the specification lan- 
guage of EHDM can be extended to include processes and interval logic specifications. 


Part I 

Part I: Interval Logic for the 
Verification of Real Time Systems 



Section 1 

The Use of Interval Logic 
for the Verification 
of Real Time Systems 


Temporal logic has been found useful for specifying distributed asyn- 
chronous systems. Traditionally, such specifications have been expressed 
as interacting machines, but that approach inevitably suffers from over 
specification, for the state machines represent an implementation. If the 
application is such that only one implementation is envisaged, an implemen- 
tation oriented specification may be acceptable; but other applications, for 
example, co mmuni cations protocol specifications, envisage many distinct 
implementations. By specifying the minimum required externally visible 
behavior, leaving all other aspects to lower levels of description, one can 
obtain a more general specification that reflects the necessary requirements 
of the distributed system or protocol. A specification that is oriented to- 
wards one implementation may discourage or even preclude other equally 
valid implementations. Specifications expressed in temporal logic do not 
suffer as severely from implementation bias as do state machine specifica- 
tions. 

A specification for a distributed system can serve to define the externally 
observable function of the system, in effect the service provided by 
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the system. Such specifications axe called service specifications. A service 
specification regards the entire distributed system as a single entity, with 
multiple interfaces at separate nodes of the distributed system. The specifi- 
cation defines how operations at each interface, performed asynchronously, 
affect results at other interfaces. Ideally, a service specification defines 
only the behavior visible at the external interfaces, without suggesting any 
internal structure for the system. 

Many service specifications define that all operations at the external 
interfaces be serializable, a characteristic that is often desirable for user 
interfaces. Such specifications can often be expressed with simpler specifi- 
cation languages that provide only the concepts of parallel operation and 
of atomicity. 

Alternatively, a specification can define the manner in which the sep- 
arate components of the distributed system interact with each other so 
as to provide the required function. Such a specification is called an im- 
plementation specification or a protocol specification. An implementation 
specification defines separately the behavior of each component, so that 
each distributed component can be implemented separately. The specifi- 
cations describe how the components communicate with each other using 
a co mmuni cation facility, which is defined by a service specification, as is 
shown in Figure 1.1. The communication facility is, of course, itself a dis- 
tributed system for which there is, in addition to the service specification, 
also an implementation specification dependent on an even more primitive 
communication mechanism. In many distributed systems, the hierarchy of 
such specifications is several levels deep. 

If there are to be several independent implementations of some of the 
components, in the future even if not immediately, it is important that the 
implementation specification describe only how the components interact 
with each other without unnecessarily constraining the internal implemen- 
tation of any component. The ideal specification is one in which 
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• any component, that satisfies its specification, will operate satisfac- 
torily in the system, and 

• any component, that operates satisfactorily in the system, will satisfy 
the specification. 

If both a service specification and an implementation specification have 
been constructed for a distributed system, it is possible to validate the im- 
plementation specification by confirming that it satisfies the service speci- 
fication. This ability is very valuable for the implementation specification 
is often quite complex and prone to error, while the service specification 
is much shorter and simpler. Unfortunately, the current state of the art, 
and particularly of tools, has not yet advanced to the point at which such 
a validation is feasible for typical distributed systems. 




Fig. 1 Specification of a Level in the Protocol Hierarchy 
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Section 2 

The Basic Interval Logic 


In a previous survey paper we examined how several different temporal 
logic approaches express the conceptual requirements for a simple protocol. 
Our conclusions were both disappointing and encouraging. On one hand, 
we saw how the very abstract temporal requirements provided an elegant 
statement of the minimal behavior for an implementation to conform to 
the specification. We were able to distill a set of requirements express- 
ing the essence of the desired behavior, stating only requirements without 
implementation-constraining expedients. 

While we were happy with the level of conceptualization of the specifi- 
cations, their expression in temporal logic was rather complex and difficult 
to understand. The relatively low level of the linear-time temporal logic 
operators encourages the inclusion of additional state components that are 
not properly part of the specification, but that help to establish the context 
necessary to express the requirements. Without these components, context 
can only be achieved by complex nestings of temporal “until” constructs 
to establish a sequence of prior states. The survey paper showed how the 
introduction of state simplifies the temporal logic formulas at the expense 
of increasing the amount of “mechanism” in the specification. The specifi- 
cation that defined only the minimum required externally visible behavior, 
without any additional internal state components, was also the least read- 
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able. As a result of this survey, the interval logic was developed to allow 
the specification of distributed systems in a manner that corresponds more 
closely to the intuitive intent and understanding of the designers. 

At the heart of our interval logic are formulas of the form: 

[/]« 

Informally, the meaning of this is: “The next time the interval I can be 
constructed, the formula a will ‘hold’ for that interval.” This interval 
formula is evaluated within the current interval context and is vacuously 
satisfied if the interval I cannot be found. A formula ‘holds’ for an interval 
if it is satisfied by the interval sequence, with the present state being the 
beginning of the interval. 

The unary □ and O temporal logic operators retain their intuitive 
meaning within interval logic. The formula [/]□<* requires that property 
a must hold throughout the interval, while [ I }Cx* expresses the property 
that sometime during the interval J, a must hold. For simple state predicate 
P, the interval formula [ I ]P expresses the requirement that P be true in 
the first state of the interval. 

Interval formulas compose with the other temporal operators to derive 
higher-level properties of intervals. The formula 

[I][j]a 

states that the first J interval contained in the next I interval, if found, will 
have property a. The property that all J intervals within interval I have 
property a would be expressed as [ J ] □[ J ] a. More globally, the formula 
□[ I ]a requires all further I intervals to have property a. 

Each interval formula [ I ] a constrains a to hold only if the interval 
I can be found. Thus only when the context can be established need the 
interval property hold. To require that the interval occur, one could write 
-i [ I ] False. The interval language defines the formula * I to mean exactly 
this. 


5 


Thus fax, we have described how to compose properties of intervals 
without discussing how intervals are formed. At the heart of a very general 
mechanism for defining and combining intervals is the notion of an event. 
An event, defined by an interval formula /?, occurs when (3 changes from 
False to True, i.e., when it becomes true. In the simplest case, (3 is a 
predicate on the state, such as x > 5 or at Dq . Note that, if the 
predicate is true in the initial state, the event occurs when it changes from 
False to True, and thus only after the predicate has become False. 

Intervals are defined by a simple or composed interval term. The prim- 
itive interval, from which all intervals are derived, is the event interval. An 
event, defined by (3, denotes the interval of change of length 2 containing 
the -i (3 and /? states comprising the change. Pictorially, this is represented 
as 
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-/» | fi 

event /? 
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Two functions, before and end, operate on intervals to extract unit inter- 
vals. For interval term I, before/ denotes the unit interval containing the 
first state of interval I. Similarly, end I denotes the unit interval at the end. 
Application of the end function is undefined for infinite intervals. Again, 
pictorially, the intervals selected are 




I 


For a P predicate event, the following formulas are valid. 
[endP]P 
£ before P ] ~ 'P 

[PhP 
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2.1 The Interval Operators=^ and *4= 

Two generic operators exist to derive intervals from interval arguments. 
We take the liberty of overloading these operators to allow zero, one or two 
interval-value arguments. Intuitively, the direction of the operator indicates 
in which direction and in which order the interval endpoints axe located. 
The endpoint at the tail of the arrow is first located, followed by a search 
in the direction of the arrow for the second endpoint. A missing parameter 
causes the related endpoint to be that of the outer context. 

The interval term I =► denotes the interval commencing at the end of 
the next interval I and extending for the remainder of the outer context. 
The right arrow operator, in effect, locates the first I interval, relative to 
the outer context, and forms the interval from the end of that I interval 
onward. With only a second argument present, => J denotes the interval 
commencing with the first state of the outer context and extending to the 
end of the first J interval. Thus, 
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The term / =>■ J, with two interval arguments, represents the compo- 
sition of the two definitions. This constructs the interval starting at the 
end of interval I and extending to the end of the next interval J located 
in the interval I =►. Given this definition, the interval formula [ I =>• J ]a 
is equivalent to [*■►][ =>• J ] a. Recall that the formula [ I =*► J ] a 
is vacuously true if the I =>• J interval cannot be found. Pictorially, the 
interval selected is 
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t— ] 

4 ♦ 

I J 

The right arrow operator with no interval arguments selects the entire 
outer context. 

The left arrow operator <= is defined analogously. For interval term 
I 4= J, the first J interval in context is located. From the end of this J 
interval, the most recent I interval is located. The derived interval I -4= J 
begins with end I and ends with endJ. Thus, 

E — 1 

t k 1 

I I J 

Similarly, the interval term I <= selects the interval beginning with the end 
of the last I interval and extending for the remainder of the context. For 
a context in which an interval I occurs an infinite number of times, the 
formula [ J <= ] a is vacuously true. The interval terms -4= and <= J are 
strictly equivalent to =>■ and =>■ J, respectively. 

The following examples illustrate the use of the interval operators. 

[x = y =► y = 16]Dx>z (2.1) 

[ nx> z ] 

4 4 

x — y y = 16 


For the interval beginning with the next event of the variable x becoming 
equal to y and ending with y changing to the value 16, the value of x is 
asserted to remain greater than z. The first state of the interval is thus 
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the state in which x is equal to y and the last state is that in which y is 
next equal to 16. Note that the events x = y and y = 16 denote the next 
changes from i^y and y 16. 

To modify the above requirement to allow x > z to become False as y 
becomes 16, one could write 

[ X = y => before(y = 16)] □ x > z (2.2) 

Nesting interval terms provides a method of expressing more compre- 
hensive context requirements. Consider the formula 

[{A=>B)=>C]OD (2.3) 

[ o ° .] 

>| h >| 

A B C 

The formula requires that, if an A event is found, the subsequent B to C 
interval, if found, must sometime satisfy property D. The outer => operator 
selects the interval commencing at the end of its first argument, in this case, 
at the end of the selected A => B interval. The interval then extends until 
the next C event - establishing the necessary context. 

In the previous example, the formula was vacuously true if any of the 
events A,B, or C could not be found in the established context. In order 
to easily express a requirement that a particular event or interval must be 
found if the necessary context is established, we introduce an interval term 
modifier *. For interval term I, *1 adds an additional requirement that B 
must be found in the designated context. The formula 

[{A=> *B)=>C]OD (2.4) 

strengthens formula (3) by adding the requirement that, if an A event 
occurs, a subsequent B event must occur. This is equivalent to formula (3) 
conjoined with [ A =»► ] *B. 
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The * modifier can be applied to an arbitrary interval term. The formula 
[ * (A=> B) => C for example, would be equivalent to (3) conjoined 

with *(A=>B), or equivalently, *A A [ A => ] *B. The * modifier 
adds only linguistic expressive power and can be eliminated by a simple 
reduction (given in the Appendix). 

As an example of specifying context for the end of the interval, consider 
the formula 

[A=* (£=>■ C) ]<>D (2.5) 

L 

M >| ►! 

A B C 

Here, the interval begins with the next occurrence of A and terminates with 
the first C that follows the next B. 

By modifying formula (3) to begin the interval at the beginning of 
A=> B, i.e., 

[ before (A => B) =b- C ] <>.D (2.6) 

[ ££_] 

1=5 

A B C 

we obtain a requirement similar to that of (5), but allowing events B and 
C to be arbitrarily ordered. 

Introducing the use of backward context, to find the interval A ■=> B in 
the context of C, we have 


[(A=»£) <=C]OD 


(2.7) 
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' qd ; 


B 


Here the occurrence of the first C event places an endpoint on the context, 
within which the most recent A =>■ B interval is found. Note the order of 
search: looking forward, the next C is found, then backward for the most 
recent A, then forward for the next B. Thus, the formula is vacuously true 
if no B is found between C and the most recent A. 

As a last example, consider 

[ before (A •£= B) -<= C ] <0 >D (2.8) 

t 

h H 1 

A B C 

The interval extends back from the first C event to the beginning of the 
most recent A •$= B interval. 


2*2 Parameterized Operations 

Within the language of our interval logic we include the concept of an ab- 
stract operation. For an abstract operation O, state predicates at O, in O, 
and afterO are defined. These predicates carry the intuitive meanings of 
being “at the beginning”, “within”, and “immediately after” the opera- 
tion. Formally, we use the following temporal axiomatization of these state 
predicates. 

1. [ atO before afterO ] QinO 
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[ afterO before atO ] Q ~>inO 
[ -iatO =► afterO ] D ~ 'atO 
[ afterO =>■ at O ] D —| afterO 

Axioms 1 and 2 together define inO to be true exactly from atO to the state 
immediately preceding afterO. Axiom 3 allows atO to be true only at the 
be ginning of the operation, and axiom 4 requires that afterO be true only 
immediately following an operation. Note that, in axiom 1 for example, 
the predicate atO used as an event term defines the interval commencing 
with the entry to the operation. 

The axioms do not imply any specific granularity, duration or mapping 
of the operation symbol to an implementation. Any interpretation of these 
state predicate symbols satisfying the above axioms is allowed. In addition, 
no assumption of operation termination is made. To require an operation 
to always terminate, one could state as an axiom 

[ at O => * after O ]True 

Abstract operations may take entry and result parameters. For an op- 
eration taking n entry parameters of types T\, . . . , T n , and m result param- 
eters of types T„+i, . . . , r„+ m , the at and after state predicates are overloaded 
to include parameter values. *tO(vi, . . . , v n ) is true in any state in which 
atO is true and the values of the parameters are «i,. . . ,v». The predicate 
after is similarly overloaded. 

As an example of an interval requirement involving parameterized oper- 
ations, consider an operation O with a single entry parameter. To require 
that this parameter increase monotonically over the call history, one could 
state 

1 Va, 6 □[atO(a) => atO(6) ] b > a 

Since a and b are free variables, for all a and b such that we can find an 

! 


2. 

3. 

4. 
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interval commencing with an atO(a) and ending with an at 0(b), b must be 
greater than a. Recall that the formula is vacuously true for any choice of 
a and b such that the interval cannot be found. 

It is also useful to be able to designate the next occurrence of the oper- 
ation call, and to bind the parameter values of that call. The event term 
at O : (a) designates the next event atO and binds the free variable o to 
the value of the parameter for that call. Thus the previous requirement 
constraining all pairs of calls, can be restated in terms of successive calls as 

□ [ atO(a) =>• atO : (6) ] 6 > a 

The requirement is now that for every a, the call atO(a) is followed by 
a call of O whose parameter is greater than o. This parameter binding 
convention has a general reduction, which we omit here. For this specific 
formula, the reduction gives 

□ [ atO(a) =► ] ( [end atO J at 0(b) ) D [ =► at O ] b > a 


2.3 Some Example Specifications 

Consider a queue with two operations, Enq which takes a single parameter 
value, which it enqueues, and Dq which removes the value at the front of the 
queue and returns that value as its result. We assume in this specification 
that the queue is unbounded, and require that values enqueued must be 
distinct. No assumptions are made about the atomicity of, or temporal 
relationships between, the Enq and Dq operations. These operations can 
overlap in an arbitrary manner. We do assume that at most one instance 
of the Enq and Dq operations will be active at any given time. 

The specification expresses the fundamental first-in first-out behavior 
that characterizes a queue. It requires that, for all a and 6, if we dequeue 
b, then any other value a will be dequeued in the interim if and only if it 
was enqueued prior to b. Further axioms are needed to express liveness 
requirements on the two operations. 
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Queue. [ <= afterDq(6) ] (*aft«rDq(a) = *(atEnq(a) •<= atEnq(6) )) 


As a second example, consider a specification to ensure exclusive access 
to a shared critical section by some set of processes. Each process is to make 
an independent decision based on a shared global data structure. In stating 
the specification, we assume a state predicate cs(i') which, for process t, 
indicates that * is in the critical section. For a shared global data structure, 
we assume a state predicate x(i) which, for process t, indicates t’s intention 
to enter the critical section. We wish to state minimal requirements on the 
use of state predicate x by a process to ensure mutual exclusion. Pictorially 
we represent the required behavior as follows: 


C1L 

h — 

*x(t) 


□x(t) 

O-'X(j) 


} 



As shown, an entry of the critical section by process t must be preceded 
by an earlier setting of x(i) to true. Throughout this interval x(z) must 
remain true, and, for every other process j, there must be some moment 
within the interval at which x(j) is false. This specification imposes no 
requirement on the order or frequency of inspecting the x(j)s; it suffices 
that, at some time during the interval, each x(j) is false. Herein lies the 
basic reason for exclusion. x(t) remains true through the interval, and no 
other x(j) can be true for that interval. Thus no other process j can find 
x(t) false between the time that » signals his intention and the time that i 
leaves the critical section (or abandons his claim). The specification does 
not, however, ensure the absence of deadlock. 

In interval logic, we express these requirements as follows. 
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Init. Vm ->x(m) 

Al. i^j D [x(0 •<=«(») ]0-*(;) 

A2. cs(t) D x(t) 


Given an initial condition in which all processes have relinquished their 
claims, axiom Al expresses our previous pictorial requirement that, if pro- 
cess * enters the critical section, then for the interval back to the most 
recent setting of x(t) , each x(j) must be found to be false. Axiom A2 re- 
quires that x(t) remains true while i is in the critical section. We have not 
needed to state explicitly that there must be a setting of x(t) prior to the 
entry; this is deducible from the specification. Similarly we can deduce that 
x(t) remains true through that interval. 

From this specification, we can demonstrate (omitted here) the mutual 
exclusion property that henceforth no pair of processes can both be in the 
critical section at the same time, i.e., 

Vm -oc(m) A * i= j 3 □ ->( cs(t)Acs(j) ) 
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Section 3 

Extending Interval Logic 
to Real Time Systems 


Temporal logic has suffered from its orientation towards eventuality rather 
than immediacy in real time; indeed, pure temporal logic makes no reference 
to time! A temporal logic specification defines only invariants, eventuality, 
and order constraints on the sequence of states resulting from the execution 
of the distributed system without reference to when the states actually oc- 
cur. But the specification of distributed systems typically depends critically 
on the specification of real time properties. 

Surprisingly, in view of the orientation of temporal logic towards even- 
tuality, there are useful eventuality properties, superficially independent 
of real time, that cannot be written without reference to real time. As 
an elementary example, the service specification for an elevator, without 
consideration of the possibility of elevator failure, can be expressed as a re- 
quirement that if a request is made for floor a then, eventually, the elevator 
will be at floor a with the door open. 

□ ( Request(o) D O atfloor(o) A dooropen(a) ) 

Unfortunately, any practical elevator inevitably has occasions when it 
is out of service, as expressed as 
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□ <0>-t inservice. 

If we are to avoid expedients such as regarding an out of service state 
as a terminal state, or of requiring that the elevator remember the request 
for floor a through the out of service state (an unreasonable requirement), 
we would like to modify the service specification to state that the elevator 
will eventually be at floor a unless it goes out of service first. There is no 
way to express that requirement; the best that can be achieved is 

□ ( request (a) D O ((atfloor(a) A dooropen(o)) V inservice) ) 

Careful examination shows that this specification is completely satisfied 
by the eventual out of service condition and it thus contributes nothing to 
the requirement that a request be serviced by moving to the requested floor. 
In effect, the elevator can satisfy the specification doing nothing but wait 
until it breaks. 

To overcome this problem, we must place a real time bound on the pe- 
riod of time throughout which the elevator must be operational to guarantee 
that the service will be provided. The service specification then becomes: 

□ [ request(o)+max_service_time j 

□ inservice D O (atfloor(o) V dooropen(o)) 

This states that for an interval commencing with the request and of 
length max-service.time, if the elevator is never out of service during the 
interval, then the service will be provided within that interval. 


Thus we need to extend interval logic to include real time constraints, 
but we do not want, in so doing, to destroy what is valuable about the 
logic. Temporal logics are valuable because they allow the expression of 
necessary properties while precluding other forms of expression that would 
be inappropriate. For example, if time is represented explicitly as a numeric 
variable in our specifications, it is possible to express any useful temporal 
property, including those involving real time constraints. But, the explicit 
representation of time makes possible expressions that have no meaning, 
such as those in which a property depends on whether the time is even or 
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permit the construction of undesired expressions in which time is manipu- 
lated inappropriately. 

The decidability of interval logic is unaffected by these extensions. It 
is not appropriate to digress here into a lengthy analysis of decidability, 
but rather we give only a brief outline of the necessary extensions to the 
decision process. A decision procedure for interval logic can be constructed 
as a standard semantic tableau, building a graph of possible states. The 
transitions between states are determined by the order of events, and thus 
the predicates on the states comprise the conjunction of the normal state 
predicates with a set of relations on the order of events. 

To extend this semantic tableau decision process to the real time ver- 
sion of interval logic, the real time relational operators are first reduced 
to terms involving event constructors, as described above. The semantic 
tableau procedure is applied, as before, but order relations on events are 
regarded as linear inequalities in a real number domain, and real time event 
constructors are replaced by arithmetic operations in that domain. Linear 
arithmetic and linear inequalities in a real number domain are decidable by 
a Presburger procedure, thus maintaining the decidability of the logic. 


3.1 The Elevator Example 


The objective of the Interval Logic specification is to express precisely 
and formally the behavior required from the elevator, including its behavior 
under failure conditions. It is also an objective to express as few constraints 
on that behavior as possible while still ensuring correct behavior. It is, per- 
haps, easier to provide a specification that describes the elevator in minute 
and mechanistic detail, but to do so precludes, or at least makes much less 
obvious, many valid implementations that are structured rather differently. 
Our specification, indeed, permits quite a wide range of behaviors; elevators 
can still be found in operation that demonstrate some of the less obvious 
strategies permitted by the specification. 
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odd! Thus the extension must not expose the numeric nature of time. 

Further, temporal logics mask quantifications over time. An explicit 
representation of time could require that those temporal quantifications 
be explicit, complicating both the formulae and also deduction involving 
the formulae. If it is possible to hide the quantifiers, and to process them 
automatically during deduction, as it is with temporal logics, we should try 
to do so. 

The interval logic can be extended to include real time by: 

• imposing real time bounds on the length of intervals, and 

• allowing events to be defined by real time offsets from other events. 

Defining events by real time offsets is achieved by two new operators 
+, — syntactically defined by 

+, — : event x duration constant — * event. 

Thus if E is an event then so are E + 1 second and E — 1 day. 

Bounds on the length of intervals are provided by two relational opera- 
tors, syntactically defined by 

>, <: duration constant — * boolean. 

These relational operators are monadic because they relate the length of 
the enclosing context to the duration constant. Used within an interval, 
they therefore relate the length of that interval to the constant. Thus, if 
I is an interval, [/] <1 second is a boolean predicate on the length of that 
interval. Similarly, we might write [I] >10 seconds A O x=4. 

The relational operators can be derived form the event constructors 
by defining a event offset from the start of the interval and determining 
whether that event lies within the interval. However, the availability of the 
relational operators adds directness and clarity to the specifications. 

These extensions to interval logic axe clean and appear sufficient to de- 
scribe almost all real time constraints directly and easily. They do not 
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Floors 


The floors are 0 to n, and the elevator will not go outside this range. There 
can be no down button on floor 0, and no up button on floor n. 

1. -»atfloor(— 1) A ~>atfloor(n + 1) 

2. ->light(0, down) A -•light (», up) 

3. -i request (0, down) A -request (», up) 

The elevator is at only; one floor at a time and moves only to adjacent 
floors. 

4. 6/a A atfloor(a) D ->atfloor(6) 

5. [atfloor(a)=>-b«fore(atfloor(a + 1) V atfloor(a — 1))] natfloor(a) 

Derived Predicates 

To simplify the specifications, we introduce a derived event newsrequest, 
since requests are significant only if there is not already an outstanding 
request, if the elevator does not already have its doors open at the requested 
floor, and if the elevator is in service. 

6. newrequest(a, dir) = request (a, dir) 

A ->light(o,dtr) A closed(a) A inservice 

We also introduce an auxiliary event decision to represent the moment 
at which the elevator decides what to do next. The event decision(a) occurs 
sometime after the doors open and before the elevator leaves at that floor. 
If the elevator does not stop at floor a, the event occurs some time between 
being at floor and not being at floor a. Note that, at the time of the event 
decision(a), atfloor(a) must still be true. 

7. [atfloor(a)=^b«for*-'atfloor(o)]-t * open(a) D * decision(o) 

8. [(atfloor (a) =^open(a) ) =^b«for*->atfloor(a) ] * decision(a) 

The predicate goingup is introduced to represent the decision made by 
the elevator about which direction to move. The predicate is true if the 
next floor that will be visited is above the current floor, and false if it is 
below. 
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It must, of course, retain that value until the next decision point. The 
curious option of re mainin g at the same floor and thus m a kin g a second 
decision at that floor is necessary in the case that the elevator arrives at 
a floor in response to a request indicating continued travel in the same 
direction, but the request then made inside the elevator is for travel in the 
other direction. The real time constraint is imposed to allow the passengers 
time to enter the elevator and press a button. 

9. [((atfloor(a) A goingup = u)=>decision(a)) 

=>-b«for«decision : (&)]> minjopen.time 

A 6 > a D □ goingup 
A b < aD □ -igoingup 
A 6 = a D □ goingup = v 

|[ > minopentime ] 

►! >1 ' > 1 

atfloor(a) decision(a) beforedecision: (6) 

A goingup=v 


Lights 

The lights are used not only to represent the lights visible to the pas- 
sengers, but also to provide the memory of pending requests. Others might 
prefer to introduce an additional predicate to represent the pending re- 
quests explicitly. 

While out of service the lights must not be lit, and following a return 
to service the lights must not be lit until a new request has been made. 

10. [->inservice^(inservice^b«for«newrequest (a, dir)) ] □ -ilight(a, dir) 

[ □~'light(a,dt'r) ] 

*\ >| >| 

-i inservice inservice newrequest(a, dir) 

Three axioms define when the lights must not be lit between the satis- 
faction of a request and the making of the next request. The case for 
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the elevator light is simple, but the other cases must consider the direction 
of motion of the elevator and also ensure that the prohibition applies from 
the first time that the doors open at that floor. 

11. [ open (a ==> beforenewrequest( a, elevator) j □ --light (a, elevator) 

[ D" 1 light(o, elevator) ] 

>j *| 

open(a) newrequest(a,lift) 

12. [before((atfloor(a)=>open(a))*$=open(a)*$=atfloor(a + 1)) 

=>beforenewrequest (a, up)] □ --light (a, up) 

□ ~-light(a,up) 


atfloor(a) open(a) atfloor(a + 1) 

open(o) newrequest(a,up) 



13. [b«fow((atfloor(a)=>-open(a))-^open(a)-<=atfloor(a — 1)) 
=>beforenewrequest (a, down) ] □ flight (a, down) 


□ -ilight(a, down) 



| f 

y 

: j 


H 


atfloor(a) open(a) 
open(a) 


atfloor(o — 1) 

newrequest(a, down) 


Another axiom defines when the lights are required to be illuminated. 
The lights can be turned off as early as the previous decision point, i.e., 
shortly before reaching the requested floor. They can remain lit for longer, 
but other axioms require that they be out at least by the time that the 
doors are open at the requested floor. The lights need only remain on so 
long as the elevator is in service. 
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14. [newrequest (a, dir ) => 

b«fore (dec is ion : (6)<= decision(a) A ((dir = up A goingup) V 

(dir = down A “'goingup) V 
dxr =elevator)) ] 

□inservice D □ light(a,d*r) 

A [=>“> inservice] □ light (a, dir) 

[ Dlightfa, dir) ] 


newrequest (a, dir) decision : (6) decision(a) 

Movement 

This axiom is an elevator scheduling constraint that requires continued 
motion in one direction so long as there are further requests outstanding in 
that direction. When the elevator decides to change its direction of motion, 
i.e., when goingup changes from false to true or from true to false, there 
must be no further request outstanding in the original direction of motion. 

15. b < a D [beforegoingup^]atfloor(o) D -> light (6, dir) 

16. 6 > a D [b«for*-igoingup=>-]atfloor(o) D — »light(6, dir) 

When appropriate, the elevator will stop find open its doors. Fast ele- 
vators need time to decelerate and stop, time that is not provided by this 
version of the specifications. The necessary modifications do not affect these 
two axioms but rather impose a speed dependent advance on the decision 
point defined in axiom 7. 

17. b > a D [(decision(o) A goingup A (light (6, up) V light (6, elevator))) 

=>-iatfloor(6)]* open(fe) V * “> inservice 

*-> inservice 
V * open (5) 

4 

decision(a) -iatfloor(6) 


1 
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18. 6 < a 


D [(decision(a) A “'goingup A (light (6, down) V light (6,elevator))) 
^>— iatfloor(6)]* open(6) V * -’inservice 

These requirements allow the wide range of behavior that we encounter 
in elevators, as for instance in allowing the elevator to always return to the 
ground floor, in allowing the elevator a home floor when inactive, or even 
in allowing the cattle car to stop at every floor regardless. 

The local liveness axioms require that the elevator should not stay at 
one floor indefinitely if there are requests outstanding from other floors. 

The first of the two axioms constrains the doors to close within a time 
constraint if they are not obstructed. The second requires timely movement 
to an adjacent floor if the elevator is in service. 

19. b # a D [(open(a) A light(6, d*r))=>- 

(open(a) A light (6, dir )) + max_open_time] 

□ (inservice A -'obstructed(a)) D * closing(a) 

£ *closing(a) J 

H *1 

open(o) A light (6, dir) open(a) A light(6, dir) 

+max_open_time 

20. b^a D [(closed(a) A light (b, dir)) => 

(closed(a) A light (6, dtr)) + movement-time] 

□ inservice D (*atfloor(a + 1) V * atfloor(a — 1)) 

*atfloor(a + 1) V 
£ *atfloor(a - 1) J 

H >1 

closed(a) A light (6, dir) closed(o) A light (6, dir) 

+movement_time 

Service Specification 

We must next provide our elevator with a service specification. Basically, 
the service specification states that if a request is made for floor o, then 
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eventually the elevator will be at floor a with the doors open. As discussed 
above, we must temper this idealistic requirement with the possibility that 
the elevator may go out of service. We must also allow for the possibility 
that the doors may be obstructed to prevent them from closing. We can 
now state an informal service requirement: 

If a request is made for floor a by pressing a button inside the elevator , 
or at that floor, and if, throughout a sufficiently long interval commencing 
with the request, the elevator is never out of service and the doors are never 
obstructed, the elevator will eventually be at floor a with its doors open. 


21. [newrequest(o, dir) =>-newrequest(a, dir) + max_service_time] 
□ (inservice A -■obstructed) = * open(o) 

□ (inservice A -■obstructed) 

[ = *open(q) ] 


newrequest (a, dir) newrequest (a, dir) 

+max _service_t ime 

It is possible to elaborate this requirement to allow occasional obstruc- 
tion of the doors while still guaranteeing service, but at the cost of greatly 
complicating the specification. The complexity arises not from any inability 
of the specification language but from the inherent complexity of determin- 
ing to what extent it is possible to obstruct the doors while still requiring 
the elevator to provide timely service. 

Door opening and closing 

We now encounter a sequence of relatively simple axioms that closely 
control the opening and closing of the doors. Their interest lies largely 
in the extent to which real time constraints are necessary to specify this 
aspect of the elevator. 

Opening, open, closing, and closed are complete and mutually exclusive. 
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22. opening(a) V open(a) V closing(a) V closed(a) 

A (opening(o) V open(a)) = -i(closing(a) V closed(a)) 

A (opening(a) V closing(o)) = ->(open(a) V closed(a)) 

23. [open(a)=>b«for«closing(a)] □open(a) 

A [closed(a)=»b«foreopening(a)] □closed(a) 

The elevator must be at a floor to open its doors and the doors of the 
elevator and that floor open and close together. 

24.opening(elevator) = 3a : 0 < a < n A opening(o) 

25. 0 < a < n D [opening(a) =>-closed (a) ] Datfloorfa) 

A opening(elevator) = opening (o) 
A open(elevator) = open(o) 

A closing(elevator) = closing(o) 

A closed (elevator) = closed(o) 

The next five axioms place real time constraints on the sequence of 
opening and closing actions of the doors, allowing for the possibility that 
the doors may be obstructed. The last axiom states that the doors axe only 
obstructed while closing. 

26. [op ening(o)=>open(a)] □ inservice D < opening-time 

27. [closing(a)=»closed(a)] □ (inservice A -’obstructed(a)) 

D < closing-time 

28. [obstructed (a) =>opening (a) ] □inservice D < reaction-time 

29. [(obstructed(a)=>open(a))^closing(a)] □inservice D < dwell-time 

30. [open(a) =>c losing (a) ] > min.open_time 

31. [obstructed(a)=>]closing(a) 
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Part II 


Extending Interval Logic to 
Include Processes 



Section 4 

Extending Interval Logic 
to include Processes 


4.1 Introduction 

Temporal logic has been found useful for specifying distributed asynchronous 
systems. Traditionally, such specifications have been expressed as inter- 
acting state machines, but that approach inevitably suffers from a risk 
of over specification since the state machine describes an implementation 
rather than the requirement. If the application is such that only one im- 
plementation is envisaged, an implementation oriented specification may 
be acceptable. Other applications, for example communications protocol 
specifications, envisage many distinct implementations. By specifying the 
minimum required externally visible behavior, leaving all other aspects to 
lower levels of description, a more general specification can be obtained that 
reflects the essential requirements of the distributed system or protocol. A 
specification that is oriented towards one implementation may discourage 
or even preclude other equally valid implementations. Specifications ex- 
pressed in temporal logic do not suffer as severely from implementation 
bias as do state machine specifications. 


27 


Specifications for distributed systems can serve two purposes: 

• Service specifications define the externally observable function, the 
service, provided by the system. 

• Implementation or protocol specifications define the manner in which 
the separate components of the distributed system interact to provide 
the required function. 

The service specification for a distributed system defines the externally 
observable function of the system, in effect the service provided by the 
system. A service specification regards the entire distributed system as a 
single entity, with multiple interfaces at separate nodes of the distributed 
system. The specification defines how operations at each interface, per- 
formed asynchronously, affect results at other interfaces. Ideally, a service 
specification defines only the behavior visible at the external interfaces, 
without suggesting any internal structure for the system. 

Many service specifications define that all operations at the external 
interfaces be serializable, a characteristic that is often desirable for user 
interfaces. Such specifications can often be expressed with simpler specifi- 
cation languages that provide only the concepts of parallel operation and 
of atomicity. 

The implementation or protocol specification for a distributed system 
defines the manner in which the separate components of the distributed 
system interact with each other so as to provide the required function. The 
internal implementation of a non-trivial distributed system is rarely serial- 
izable, and thus the language for expressing implementation specifications 
requires more flexibility. 

An implementation specification defines separately the behavior of each 
component, so that each distributed component can be implemented inde- 
pendently. The specifications describe how the components communicate 
with each other using a communication facility, which is defined by a ser- 
vice specification, as is shown in Figure 4.1. The communication facility 
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is, of course, itself a distributed system for which there is, in addition to 
the service specification, also an implementation specification dependent on 
an even more primitive communication mechanism. In many distributed 
systems, the hierarchy of such specifications is several levels deep. 




Figure 4.1: Specification of a Level in the Protocol Hierarchy. 

If there are to be several independent implementations of some of the 
components, in the future even if not immediately, it is important that the 
implementation specification describe only how the components interact 
with each other without unnecessarily constraining the internal implemen- 
tation of any component. The ideal specification is one in which 

• any component, that satisfies its specification, will operate satisfac- 
torily in the system, and 

• any component, that operates satisfactorily in the system, will satisfy 
the specification. 
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If both a service specification and an implementation specification have 
been constructed for a distributed system, it is possible to validate the im- 
plementation specification by confirming that it satisfies the service speci- 
fication. This ability is very valuable for the implementation specification 
is often quite complex and prone to error, while the service specification 
is much shorter and simpler. Unfortunately, the current state of the art, 
and particularly of tools, has not yet advanced to the point at which such 
a validation is feasible for typical distributed systems. 


4.2 Service and Implementation 
Specifications 

The service specification is intended to describe only the service provided 
to the user that he can depend on obtaining from all implementations, 
that is the externally observable behavior required of all implementations. 
The service specifications should allow as much flexibility as possible in the 
internal implementation of the system, and thus should avoid describing 
internal structure so far as is possible in a specification that is easy to 
understand. 

Because the service specification describes a distributed system with 
several external interfaces that operate asynchronously, it is to be expected 
that the specification will have to describe asynchronous operation of those 
interfaces. But the service specification is intended to conceal rather than 
to reveal the internal component structure of the implementation, and the 
internal process structure should not be exposed. If these internal struc- 
tures axe visible through the service specification, the opportunities for 
hierarchical composition axe reduced. Minor changes in the design at one 
level, changes that should have been purely local, may be propagated up the 
hierarchy and may affect the specification and validation of higher levels. 

In contrast, an implementation specification describes the implementa- 
tion of a distributed system as a set of interacting components. Since the 
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system will be implemented as a distributed system, each component must 
be defined separately without reference to the specification of any other 
component. The interactions between components must be provided by 
a communications mechanism, for which a specification must also be pro- 
vided. The implementation specification aims to describe the interactions 
between components rather than their internal construction, and it is de- 
sirable that the specification leave as much flexibility as possible for the 
internal design of those components. 

Consequently, the appropriate form for an implementation specification 
consists of a set of service specifications describing each of the components, 
and of service specifications describing the communications mechanisms by 
which they interact. There may be multiple instances of some components, 
and the implementation specification should therefore be able to instantiate 
multiply a single service specification to represent those instances. The 
communication service will typically have multiple equivalent interfaces at 
which the service is provided. By specifying each service specification as a 
module of the specification language, the required flexibility can easily be 
provided by module instantiation mechanisms, which are very powerful in 
modem specification languages. 

The implementation specification should distinguish between the spec- 
ifications of components that are intended to be localized, and the specifi- 
cations of communications mechanisms that are distributed over the entire 
system. Qualifiers local and distributed should be provided for mod- 
ule declarations. For example (omitting any module parameterization for 
clarity) 

producer: local module is sensorscanner 
consumer: local module is correlator 
shareddata: distributed module is filesystem 

When defining a service specification, the interfaces take the form of op- 
erations, presumably implemented by procedure calls of the programming 
language. Some of these interfaces are provided by operations mechanized 
within the component being specified. Such operations are intended to be 
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invoked by a process from outside the component. Other interfaces are 
operations mechanized outside the component, and invoked by a processes 
from within the component. The two cases are symmetrical and, on each 
side of the interface, the same information must be provided, i.e. type 
declaration, semantic effect, etc. It is, of course, important that the dis- 
tinction between the two be clear in the specifications. Thus, it is necessary 
that the specification language, when defining an operation, should be able 
to designate the operation to be external, a feature provided quite fre- 
quently by progr amm ing languages but seldom by specification languages. 
An example of such a declaration might be 

put: external operation [ data, file [data] -> statuscode ] 

Other interfaces may be provided by means of shared data structures, and 
here again the same distinction is required. 

The implementation specification must link the interfaces of the com- 
ponents to the interfaces of the communication mechanisms. The linkage 
can be expressed by equating the two interfaces, thus: 

al: linkage producer. put s filesystem. writerecord[2] 

a2: linkage consumer. get ■ f ilesystem.readrecord[3] 

It is evident that linkage of interfaces within an implementation specifi- 
cation should be between an internal and an external construct, and only 
when they are type compatible. Direct linkage of the interfaces of two local 
components precludes a distributed implementation. 


4.3 Processes 

The concept of a process was created to describe the flow of control within 
concurrent processing contexts, and processes, or related constructs, are 
provided by progr ammin g languages that aim to support real time pro- 
gramming. In contrast, specification languages have generally avoided the 
concept of process, since flow of control is an implementation oriented con- 
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cept, distinct from the externally observable behavior defined by a specifica- 
tion. But specification languages must support not only pure specification 
but also the reasoning that is used to justify the implementation. 

At a design level, when establishing that an implementation specifica- 
tion does indeed satisfy its service specification, it is necessary to be able 
to relate, and thus to be able to distinguish, the processing of the vari- 
ous components. Processes are a convenient mechanism for expressing the 
progress of each component through its computation. To validate the im- 
plementation of a distributed system, expressed in terms of processes, the 
specification language must also support the concept of processes. 

Programming languages provide processes whose declaration introduces 
not only an (implicit) locus of control but also a relative complex program 
structuring unit, including the declaration of local variables and param- 
eters. In the purer context of a specification language, it is desirable to 
define a process solely to denote the locus of control. That declaration may 
be included within a module structure that also includes other declarations 
as required. 

The extensions to the specification language are, therefore, straightfor- 
ward. In the specification language prelude, process is declared to be a 
type, as in: 

process :type 

Processes are then declared by conventional declarations, as in: 
p: process 

As for other objects, processes may be declared to be external, represent- 
ing a process that is external to a component and that invokes operations 
declared within the component. 

In Interval Logic, as in other temporal logics, the location of control 
within the program is expressed by three state predicates, at, in and after. 
These three predicates relate the location of control to an operation. The 
operation may be primitive or composite, a primitive operation at one 
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level of abstraction being, of course, composite at a more detailed level. 
The predicates carry the intuitive meanings of the location of conrol being 
“at the beginning of,” “within” and “immediately after” the operation. 
Typically, in the past, these predicates have not defined which process is 
at that point of the computation. 

Extending these predicates to accept processes is direct, at (p,0) de- 
notes that process p is at the beginning of operation O, and similarly for 
in and after. 

It is now appropriate to consider the meaning that was intended when 
at, in and after were used without an explicit process. Generally, the 
intended meaning is intuitively clear, but the implicit quantification over 
processes required to achieve that meaning is not the same in all examples. 
Consider one of the axioms that has traditionally defined the meaning of 
at, inand after. 

[ atO => b*fow after O ] QinO 

It is clear that the intent is that the axiom be enclosed within a universal 
quantification over processes, thus: 

Vp, O : [ at (p, O) =► before af ter(p, O) ] □ in(p, O) 

But the useful statement about queues expressed as: 

□ <^at Enqueue A □ O utDequeue 

D □ fetter Dequeue 

requires local existential quantification, thus: 

□ O^p : at (p, Enqueue) A □ C>3g : at (q, Dequeue) 

D □ : af ter(r, Dequeue) 

There are other examples where various mixtures of universal and existen- 
tial quantifications are required, variously bound. Note also that, unlike 
pure predicate calculus, quantifiers cannot all be brought to the outer lev- 
els. Universal quantifiers can be promoted through □ but not through 0> 
and existential quantifiers through <0 but not through □ . 
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Even though the intended quantification over processes is intuitively 
obvious, the intuition is based on understanding of the semantics. We have 
found no systematic method by which it is possible to impute an appro- 
priate quantification to an expression in which the processes are implicit 
rather than explicit. Consequently, we prefer to reject implicit quantifica- 
tion and to require that all uses of at, in and after define explicitly the 
process and the operation. 

Formally, the three state predicates are defined by following temporal 
axiomatization. 

1. [ at (p, O) => befort af ter(p, 0) ] □ in(p, O ) 

2. [ af ter(p, O ) =>■ before at (p, 0) ] □ ->in(p, O) 

3. [ ->at (p, 0) =>> af ter(p, 0) ] □ -iat(p, O) 

4. [ -iaf ter(p, O) ^ at (p, 0) ] □ ->af ter(p, O) 

Axioms 1 and 2 together define in(p, 0) to be true exactly from at(p, 0) to 
the state immediately preceding after(p, O). Axiom 3 allows at (p,0) to 
be true only at the beginning of the operation, and axiom 4 requires that 
af ter(p, O) be true only immediately following an operation. 

The axioms do not imply any specific granularity, duration or mapping 
of the operation symbol to an implementation. Any interpretation of these 
state predicate symbols satisfying the above axioms is allowed. In addition, 
no assumption of operation termination is made. 

A further complication arises with the operation argument to at, in 
and after. Consider a process p and an operation op, declared to be of 
type operation [ t, t -> t ], with variables a and b also declared to be 
of type t. 

In the expression at(p, op(a,6)) the operation term op(a,b ) has type 
operation [ -> ] , and thus we can set the signature of the function at to 
be state! function! process, operation! “>] -> boolean ]]. But 
the Interval Logic also allows other forms for the at operator that are not 
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so easy to render type consistent. The three forms provided in Interval 
Logic are: 

• at(p, op(a, b)) which becomes true at the next state in which op has 
been called with parameters a and b 

• at (p, op) which becomes true at the next state in which op is called 
regardless of the values of the parameters 

• at (p, op : (a, b)) which becomes true at the next state in which op is 
called regardless of the values of the parameters, and which binds the 
free variables a and b to the values of the parameters at that time. 

All three forms are very useful in constructing specifications. 

The second form at (p, op) requires that at accept as argument opera- 
tions of many different types, depending on their parameterizations, and 
thus at be declared within a polyadic generic module, similar to those in 
the prelude that declare function and operation. Polyadic generic mod- 
ules are supported by Revised Special only for predefined theories built 
into the system; they cannot be defined by the user. Thus it is not possible 
to introduce at as a user defined extension to Revised Special. Indeed, 
it is clear that the appropriate place for at to be declared is within the 
operations module that declares operations that accept parameters. 

This form of at involves am implicit existential quantification. The term 
at (p, op) is interpreted to imply a term of the form 

3a, b : [— > *at(p,op(a,6)]Vc,d : at (p,op(c,d) Da = c/\b = d, 

placed in the context from which the term at (p,op) is searched for. The 
construction is essentially similar to that for *E, which introduces the 
additional term False in the context where *E indicates that event 

E must be found. We should note that, whatever the formal semantics of 
at (p, op), or in deed of *E, the decision procedure cam process the terms 
much more efficiently in their original form than in the expanded form. 
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The third form of at, at (p, op : a, b) not only requires a polyadic generic 
declaration, but also makes visible the implicit quantification inherent in 
at (p, op). Additional mechanism is required to bind the cited parameter 
values to the implicit quantification. 

It is necessary to note that the term at (p, op : a,b ) introduces a risk 
of ambiguity into the language if recursive operations are permitted. If 
control is within operation op nested two or more levels of recursion deep, 
there are alternative choices for the values of a and b. The logic defines the 
meaning to be an arbitrary choice as to which set of parameters is bound 
to a and 6. Fortunately, recursive operations are very rare in the design 
of real time systems, though reentrant operations are not. Thus we are 
careful to avoid in the language any form such as at(: p, op), which would 
be often ambiguous. 

in must be handled similarly to at, but after introduces additional 
considerations because Interval Logic permits reference to the result of the 
operation. Prior versions of Interval Logic used af ter(p, op(a)) to constrain 
the result of the operation to the value of a. This was clearly inappropriate, 
confusing the parameters of the operation with its result, and introducing 
context sensitivity, typechecking problems, and lack of expressivity. 

We therefore propose the form af ter(p, op\a) to become true in the next 
state in which control is after op and the result of the operation is equal to 
o. Indeed after(p, op!a) can be replaced by after(p, op ) Aresult = a. 

Operations, when they return a result, usually return only a single value 
as their result, unlike parameters where multiple parameters are common. 
Consequently, it appears appropriate to orient the specification mechanisms 
to a single result, as above. When a compound result must be specified, it 
can be represented as a tuple, as in after(p, opl < a, b >). 

It must also be possible to search for the next state in which control 
is after op, and to bind a variable to the result in that state. This can 
be expressed as af ter (p, op! : a), which is replaced by af ter (p, op) and 
introduces into that context an additional term [after(p,op)=3>-] result = 


37 



a. 

It is also possible to constrain both the parameters and the result of an 
operation, as in after(p, op(a, b)lc). 
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Section 5 


Extending Revised Special 
to Include Interval Logic 


Some, indeed many, parts of the Interval Logic can be introduced as user de- 
fined modules using the standard theory definition mechanisms of Revised 
Special. But there are aspects of Interval Logic that are not well handled 
by the standard mechanisms made available to users, and must really be 
provided through internal modification of the specification and verification 
system if Interval Logic is to be effective. Three of these aspects axe: 


• The binding of parameters and results to operations for the at, in, 
and after predicates, as discussed above. 

• The decision procedure for Interval Logic should be integral to the 
internal prover if it is to be effective. No axiomatization of Interval 
Logic has been developed, and if an axiomatization existed then it 
would be excessively complex. Thus, attempting to prove theorems 
in Interval logic by use of some predefined set of axioms and theorems 
would be tedious and frustrating to the user. 

• While it is possible to define Interval Logic solely in terms of prefix 
functions that can be declared in user defined modules, the result 
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lacks most of the intuitive clarity that is a major part of the value 
of Interval Logic. The infix syntax of Interval Logic complicates the 
parsing of temporal expressions, but is important to the utility of the 
logic. 

Consequently, we believe that a realistic extension of Revised Special and 
of the Enhanced HDM specification and verification system must depend 
on extensions to the code of the parser, typechecker, and prover. 


5.1 Extensions to the Syntax 

The required extensions to the syntax are quite straight forward and are 
marked below by the rule in the left margin. They are, in order: 

• Modules can be optionally qualified as local or distributed. 

• Axioms can be defined to be linkag es or as assumptions. The exist- 
ing assuming clause can be used to define assumptions about module 
parameters, but is unsatisfactory for stating assumptions about the 
behavior of constants defined to be external. The handling of as- 
sumptions is equivalent to that for formulae in the assuming clause. 

• Constants can be optionally declared to be external. 

• Temporal expressions are introduced as boolean expressions, compris- 
ing expressions prefixed by the operators henceforth, eventually 
and *, and the interval expressions denoted by [ ] . 

• Intervals are defined by the operators -> and <-, or by events. The 
arguments to the -> and <- operators are optional, and intervals can 
be prefixed by a single *. 

• An event is a boolean expression, optionally prefixed by an *. 
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• The unary prefix operators are extended to include the unary rela- 
tional operators < and >. 

• Operation application is extended to include the : and ! qualifiers. 
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5.1.1 Revised User Syntax 

The conventions of the syntactic description are: 


• italics are used to indicate syntactic classes and metavariables that 
range over syntactic classes. 

• a printer font is used to indicate language keywords, 


• choice is indicated by vertical bar 


in the normal fashion. 


• optional inclusion of a clause A is indicated by square parentheses 

M • 


• iteration of a clause B one or more times is written with braces and 
a plus sign { B }"*" . 

$ 

• repetition zero or more times is written with an asterisk { B } 

• a symbol below the plus or asterisk indicates a clause separator, i.e. 

* ♦ 
to indicate separation of each clause by a comma { B }, 


modult-decl 


modulesynonym 
module-body :: = 


local distributed 


] 


[ comment-list ] 
ident : £ 

module formaLparams j 
{module-synonym module-body 
is new J module-name comment-list 
using-clause J 

exporting-clause 

assuming -clause 


commentJist 
commentJist 
commentJist 
theory-clause ] 
proof-clause 


end 


ident J 


comment. 


-list J 


} 

] 
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using-clause :: = 

jfc I 

using { module-name }, 


* 

mapping { module-name }, onto { module-name 

exporting-clause 

exporting entity -name-list J 


■ *1 

with { module-name }, j 

assuming-clause 

* 

assuming { assuming-decl } 

assuming-decl = 

module-decl | const-decl | var-decl | type-decl 


formula-decl | commentJist 

theory-clause = 

* 

theory { theory-decl } 

theory-decl :: = 

module-decl const-decl var-decl type-decl | 


formula-decl | axiom-decl comment-list 

proof-clause 

proof [ using -clause J { proof -decl }* 

proof -decl 

module-decl | const-decl | var-decl | type-decl | 


formula-decl prove-decl | comment-list 

prove-decl 

ident : {prove | verify } 


instance-list [ from instanceJist 1 

instanceJist :: = 

{ instance }+ 

instance 

entity-name [ substitutuion ] 

substitutuion = 

{ { entity-name <- expr }, } 

formula-decl 

ident : {formula theorem | lemma } 


[synonym | formula-expr J 

formula-expr :: = 

sc-expr [ changes-clause J 

axiom-decl :: = 

ident : {axiom j assumption | linkage } 


[ synonym | formula-expr J 

var-decl ::=* 

identJist : {variable | var }type-name 


£ synonym ] 

const-decl :: = 

entity-name-list : type-name 


synonym const-expr where-clause 
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synonym :: = 

is entity-name 

eonst.expr :: = 

{= == } se.expr 

where.elause :: = 

where expr ehanges.clause 

changes.clause :: = 

changes {entity.name.list | nothing } 

type.deel = 

entity.nameJist : type [ type-syn type. 

type.syn :: = 

is type-name 

type.deriv :: = 

from type.name 

type-name 

entity.name 

formai-params = 

[ { formal.param.elt ] 

formal.param.elt :: = 

identJist 

: formal-type 

formal .type :: = 

type type-name 

entity.nameJist = 

{ entity-name 

entity-name = 

number 

{ ident [ actuaLparam 

module-name :: = 

{ ident [ actual-param ] 

actual-param = 

[ type.or.exprJist ] [-> [type.name J 

type.or.expr.list 
se.expr :: = 

{ type-name expr 
{ expr }•*" 

expr 

imp.expr 

iff imp.expr J 

imp.expr 

or-expr implies imp.expr J 

or. expr = 

and-expr 

L or or. expr J 

and-expr :: = 

temporaLexpr ^ and and-expr J 

temporal.expr :: = 

henceforth temporaLexpr 
eventually temporal.expr 
* temporaLexpr 
[ interval ] temporaLexpr 
rel.op.expr 

interval = 

* J ( int.term ) int.term 
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int-term 


event 

rel.op.expr 

plus.minus.expr 

times.or.div.expr :: ■ 

unary.minus.expr 

op.expr 

not.expr = 

mise.expr :: = 

simple-expr 


paren-cxpr 
lambda-expr 
quan-cxpr 
with-expr :: = 
assignments :: = 
if.expr :: = 
case.expr = 

case-part = 


interval 

-> 

interval 


z s 

interval 

<- 

Z 3 

interval 



event 


[ * ] ex pr 
plus.minus.expr {= 


'= < 


<= > >= } plus.minus.expr 


plus.minus.expr {+ | - } J times.or.div.expr 
times.or.div.expr {* | / } J unary.minus.expr 
op.expr | - plus.minus.expr | {< | > } plus.minus.expr 
not.expr | op.construct 
[ not J mise.expr 
simple.expr if.expr | case.expr | 
opspec.expr hoaresentence 
{entity-name 
paren-expr 
lambda-expr 
quan.expr } * J 
{with-expr * J 

({ expr }* [ : ( expr ) ] [ ! [ 

( sc.expr ) 

( lambda £ entity.name.list J -> type-name : expr ) 

( {exists | forall } entity. name-list : expr ) 

with [ { assignments }"*”] 

{ argJist [ * J } + :=* expr 

if expr then expr else expr end 
$ 

case { case-part }, 
else expr [ comment-list J end 
{expr : expr } | [ comment-list J 


] expr ] ) [ ’ ] } H 
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opspec-expr :: = 


hoaresentence ::= 
op-construct 
compound-op 
repeat-op :: = 
while-op :: = 
assign-op :: = 
identJist = 
comment-list :: = 
comment 


opspec op-expr 

r * 

case { case-part }, 

else expr £ comment-list J end 

{expr } sc-expr {expr } 

compound-op | repeat-op j while-op assign-op 

begin sc-expr end 

repeat sc-expr until expr 

while expr do op-expr 

entity-name := expr 

{ ident 

r l * 

{ comment } 

(* { Any sequence of characters except (* and *) 


comment } *) 
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5.2 Extensions to the Typechecking 


Most of the extensions to the typechecker are direct consequences of the 
extensions to the syntax, making use of an extended prelude. 

Additional special handling is required for at, in and after. These 
operators must be polyadic, as are operations. The ; and ! qualifiers also 
require special processing. 

The optionally omitted interval arguments to the -> and <- operators 
must be inserted, using the now and then interval constants. 

It is necessary for the typechecker to distinguish between two uses of 
the * monadic prefix operator. If the term occurs where an interval term is 
expected, the operator is replaced by an application of the find function; 
if a boolean term is expected, the occurs function is used. 

The type checker makes use of a extensions to the prelude: 

• the operations module includes polyadic declarations for at, in and 
after 

• the intervallogic module introduces the remaining interval logic 
functions. 

Much of the complexity of this module declaration comes from the require- 
ment that the -> and <- operators accept either intervals or events as 
arguments, thus requiring extensive overloading of the declarations. 
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5.2.1 The Revised Prelude 

The revised modules of the prelude axe: 


operation: module [ characteristic: type ] 

exporting operation, noop, compose, assignops, whileop, repeatop, hoare 
theory 

oper at ion : type 
noop : oper at ion 

(* diadic infix oparator ; *) 

compose: function[ operation, operation -> operation ] 

assignops: module [ t: type ] 
exporting assign 
theory 

(* diadic infix operator :* *) 
assign: function[ state[t], t -> operation ] 
end assignops 

(* diadic mixfix operator while _ do _ *) 

whileop: function[ boolean, operation -> operation ] 

(* diadic mixfix operator repeat _ until _ *) 

repeatop: function[ operation, boolean -> operation ] 

(* triadic mixfix operator *) 

hoare: function[ boolean, operation, boolean -> boolean ] 

at, in, after: state [funct ion [ process, operation -> boolean ]] 

end operations 
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intervallogic: module 


using operations 
exporting 

process, interval, event, now, then, Int, 
moduleee. forward, moduleee . backward , 
moduleie. forward, moduleie. backward, 
moduleei. forward, moduleei . backward , 
module ii. forward, moduleii. backward, 
modulene. forward, modulene. backward, 
moduleet .forward , moduleet . backward , 
moduleni .forward , moduleni . backward , 
module it .forward, module it .backward, 
henceforth, eventually, occurs, find, 
before, at end 

theory 

process: type 
interval: type 

event: type is state [boolean] 
now, then: const event 
vacuous, failed: const interval 

p: process 
e: event 
I: interval 
op: operation 
b: state [boolean] 

(* diadic oixfix operator [ _ ] _ *) 

Int : state [function (interval , state [boolean] “boolean) ] 

before: function (interval->interval) 
at end : f unc t ion ( int erval - > int erval ) 

(* monadic prefix operator eventually *) 

eventually: state [function (state [boolean] ->boolean)] 

(* monadic prefix operator henceforth *) 

henceforth: state [function (state [boolean] ->boolean) ] 

(* monadic prefix operator * *) 

occurs : state [function (state [boolean] ->boolean) ] 

(* monadic prefix operator * *) 

find: function (state [boolean] ->state [boolean] ) 



moduleee : module 

exporting forward, backward 
theory 

(* diadic infix operator -> *) 

forward: state [function (event , event->interval)] 

(* diadic infix operator <- *) 

backward: state [function (event , event ->interval) ] 
end moduleee 

moduleie: module 

exporting forward, backward 
theory 

(* diadic infix operator -> *) 

forward: state [function (interval , event -> interval)] 

(* diadic infix operator <- *) 

backward: state [function (interval ,event->interval) ] 
end moduleie 

moduleei : module 

exporting forward, backward 
theory 

(* diadic infix operator -> *) 

forward: state [function (event , interval->interval) 3 
(* diadic infix operator <- *) 

backward: state [function (event , interval->interval) ] 
end moduleei 

moduleii : module 

exporting forward, backward 
theory 

(* diadic infix operator -> *) 

forward: state [function (interval , interval->interval)] 
(* diadic infix operator <- *) 

backward : state [function (interval , interval->interval) ] 
end moduleii 
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modulene : module 
using moduleee 
exporting forward, backward 
theory 

(* monadic prefix operator -> *) 

forward: state [f unct i on (e vent -> interval) ] 

is (lambda e -> interval: module ie. forward (now, e)) 

(* monadic prefix operator <- *) 

backward : state [f unct ion (event -> interval) ] 

is (lambda e -> interval: moduleie. forward (now , e) ) 

end modulene 

moduleet : module 
using moduleee 
exporting forward, backward 
theory 

(* monadic postfix operator -> *) 

forward: state [f unc t i on ( e v ent - > int er val ) ] 

is (lambda e -> interval: moduleie. f orward(e, then) ) 

(* monadic postfix operator <- *) 

backward : state [f unction(event->interval) ] 

is (lambda e -> interval: moduleie. backward (e, then) ) 

end moduleet 

moduleni : module 
using moduleei 
exporting forward, backward 
theory 

(* monadic prefix operator -> *) 

forward : state [function (interval->interval) ] 

is (lambda I -> interval: moduleie. forward (now, I)) 

(* monadic prefix operator <- *) 

backward : state [f unct ion(interval->interval) ] 

is (lambda I -> interval: moduleie. backward (now, I) ) 

end moduleni 

moduleit : module 
using moduleie 
exporting forward, backward 
theory 

(* monadic postfix operator -> *) 

f orward : a t at e [f unct i on ( int erval - > int er val ) ] 

is (lambda I -> interval: moduleie. forward (I, then)) 

(* monadic postfix operator <- *) 

backward: state [f unct ion (int erval->int erval)] 

is (lambda I -> interval: moduleie. backward (I, then)) 


end moduleit 


I 


at ini: axiom 

henceforth (at (p, op) implies in(p,op)) 
atin2: axiom 

[ at(p,op) -> bef ore ( after (p, op)) ] henceforth ( in (p, op)) ) 
atin3: axiom 

henceforth(after(p,op) implies not in(p f op)) 
atin4: axiom 

[ after (p, op) -> bef ore (at (p, op) ) ] henceforth( not in(p,op))) 


vacaxioml: axiom Int (vacuous ,b) iff true 

vacaxiom2: axiom I failed implies 

forward (e .vacuous) * forward (vacuous ,e) 

» forward (I, vacuous) * forward (vacuous, I) 

* backward(e, vacuous) * backward (vacuous ,e) 

- backward(I, vacuous) - backward(vacuous,I) 

» vacuous 

failedaxioml: axiom Int (f ailed, b) iff false 

failedaxiom2: axiom forward(e, failed) * f orward (failed , e) 

* forward (I .failed) - forward (failed, I) 

- backward (e, failed) « backward(f ailed, e) 
■ backward(I, failed) * backward(failed,I) 

- failed 

end intervallogic 
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5.3 


Extensions to the Prover 


The necessary extensions to the prover are described in a subsequent section 
of the report. 
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Section 6 


An Example: Specification of 
the Alternating Bit Protocol 


This section demonstrates the use of processes in interval logic, with an 
example from the area of communication protocols, the Alternating Bit 
protocol. This protocol can be considered as a rather simple, but not 
trivial, example of a Data Link layer protocol. (The concept of layering is 
specified in the ISO OSI Basic Reference Model [IS082].) The objective of 
the Data Link layer protocol is to detect and possibly correct errors that 
may occur in the underlying Physical Link layer. 


6.1 The Alternating Bit Protocol 

The Alternating Bit protocol is used to provide a reliable message commu- 
nication over an unreliable transmission line through repeated transmission. 
It considers messages one at a time and cannot proceed to the next message 
until it receives acknowledgment that its current message has been received 
correctly. The message is placed in a packet with a one-bit sequence num- 
ber (hence the name of the protocol), and an acknowledgment is assumed 
to consist of the return of the same packet (although only the sequence 
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number is really required). Several packets may be in transit simultane- 
ously. The protocol recovers successfully from packets lost, duplicated, or 
delayed by the transmission line, as long as no packets arrive out of order. 

The scenario of sending one message can be described by assuming that 
a user process sends a message m by invoking the operation send(i.m). 

The message will be placed in the Sender queue. The Sender process de- 
queues the message (through dq!<i ,m>) and transmits it together with the 
Sender’s current sequence number was a packet through transmit (i . <message ,m,v>). 
The Receiver entity gets packets by means of receive ! <i . <message ,m. v>>. 
Acknowledgments are sent from the Receiver entity through transmit ( i . <ack , m . v> ) 
and received by the Sender entity by means of receive !<i,<ack,m,v». 

Messages from the Receiver process can be stored by enq(<i ,m>) in the Re- 
ceiver queue from which the receiving user can dequeue it by the operation 
rec!<i,m>. 

We have described here the protocol as a communication between a sin- 
gle Sender and a single Receiver. To demonstrate the process mechanisms 
better, the example specifies co mmu nication between many senders and 
receivers. Thus every user invoking the send operation must specify not 
only the message but also its destination, as must the transit operation. 

Similarly, the receive and rec operations supply a source as a part of 
their result. We assume that the sender still only sends packets one at a 
time, and does not proceed to the next message until it has received an 
acknowledgment for the previous packet, but the receiver must, of course, 
be able to receive packets from several sources simultaneously. 


6.2 Specification of the Service Used and 
the Service Provided 


The Alternating Bit protocol converts the unreliable queue service of the 
physical transmission medium into a reliable queue. The service specifica- 
tions for both the Alternating Bit protocol and of the transmission medium 


55 


are based on specifications for queues. But before proceeding to those 
relatively complex queue specifications, we first consider a simple queue 
specification that will be used to provide local input and output queues for 
the Senders and Receivers of the communication mechanism. 

The simple queue specification was introduced above, where axiom al 
was cited to require that messages be dequeued in the correct order. Ax- 
iom a2 also requires that messages be enqueued before being dequeued. 
Axioms a3 and a4 are liveness requirements; a3 ensures that messages will 
be dequeued, while a4 requires that the enqueue operation always return. 
Axiom a5 is an assumption about the behavior of the user, that every mes- 
sage enqueued is distinct, an assumption without which it is not possible 
to write the specification using temporal logic. 
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simplequeue: modal* [ data: typa ] 
reporting enq, dq, pa, pb 

theory 

pa, pb: axtarnal process 
a, b: var data 

•nq: oparation[ data -> ] 
dq: operation [ -> data ] 

al: axiom 

[ ♦(atCpa, enq(a) ) -> at (pa,onq(b))) 

<- (aft*r(pb,dqla) -> after (pb.dqlb)) ] true 

a2: axiom 

[ *at (pa,enq(a)) <- aft*r(pb,dqla) ] true 
a3: axiom 

♦at (pa, enq(a)) and henceforth *at(pb,dq) implies ♦after(pb.dqla) 
a 4 : axiom 

henceforth [ ♦at(pa,enq) <- after(pa.enq) ] true 

(* assumption about external behavior ♦) 
aB: assumption 

[ atCpa.enq(a)) -> ] b'*a implies not ♦at(at(pa,*nq(b)) 
end simplequeue 
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We next define a reliable queue serving many inputs and outputs. The 
extensions to the simple queue axe direct and obvious, except for axiom q4, 
which is new and is a fairness requirement that messages from all sources 
have a chance of being dequeued. 

The unreliable queue specification is derived from that of the reliable 
queue by modification of axioms q3 and q4. In both cases, because of the 
unreliability, a message must be sent repeatedly to ensure that it will be 
received. 
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reliablequeue: module [ id, data: type ] 
exporting interface 

theory 

i, J: var id 
a, b: var data 

interface: module [ i: id ] 
exporting pa, pb, enq, dq 
theory 

pa, pb: external process 
enq: operation [ id, data -> ] 
dq: operation [ -> tuple [id, data]] 

end interface 

ql: axiom 

[ * (at ( int erf ace [i] .pa,enq[i] (j ,a)) 

-> at (interface [i] .pa.enqCi] (j ,b))) 

<- (after(interface[j] .pb,dq[j] !<i,a>) 

-> after (interf ace[ j] .pb,dq[j] Ki,b>)) ] true 

q2: axiom 

[ *at (interfaced] .pa,enq[i] (j.a)) 

<- after (interf ace[j] .pb,dq[j] !<i,a>) ] trne 

q3: axiom 

[ *at (interf ace[i] .pa, enq[i] (j ,a)) and *at (interface [J] . pb.dqtj]) 
-> *af ter (interf ace[j] .pb,dq[j]) ] trne 

q4: axiom 

♦at (interface [i] .pa, enq [i] (J ,a)) 

and henceforth *at (interf ace[j] .pb,dq[j]) 
implies *after (interf ace[j] .pb,dq[j] !<i,a>) 

q5: axiom 

henceforth [ *at (interface [i] .pa, enq[i]) 

<- af ter (interf ace [i] .pa, enq[i]) ] trne 

(* assumption abont external behavior *) 
qfl: assumption 

[ at (Interfaced] .pa,enq[i] (j.a)) 

-> at (interfaced] .pa,enq[i] (j ,a)) ] false 

end reliableqnene 
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ORIGINAL PAGE IS 
OF POOR QUALITY 


unreliablequeue: modal* [ id, data: typo ] 
exporting interface 

theory 

i, j: var id 
a, b: var data 

interface: module [ i: id ] 
exporting pa, pb, enq, dq 
theory 

pa, pb: external process 
enq: operation [ id, data -> 3 
dq: operation [ -> tuple [id .data]] 

end interface 

ul: axiom 

[ * Cat (interfaced] .pa, enq[i] (j ,a)) 

-> at (interface [i] .pa,*nq[i] (j ,b))) 

<- (aft*r(int*rfac*[j] .pb,dq[j] !<i,a>) 

-> after (interface^] .pb,dq[j] ! <i,b>)) ] true 

u2: axiom 

[ *at (interfaced] . pa,*nq[i] (j ,a)) 

<- after (interface^] .pb,dq[j] !<i,a>) ] true 

u3: axiom 

henceforth *at (interface [i] .pa, enq[i] (j ,a>) 
and *at (interface [j ] .pb,dq[j]) 
implies *after (interface [ j] .pb,dq[j]) 

u4 : axiom 

henceforth *at (interface [i] .pa, enq[i] (j ,a)) 
and henceforth *at (interface [j] .pb, dq[j]) 
implies *aft*r (interface [j] .pb,dq[j] 1 <i f a>) 

u5: axiom 

henceforth [ *at (interface [i] .pa, *nq[i] ) 

<- after (interface [i] .pa, enq[i]) 3 true 

(* assumption about external behavior *) 
u6: assumption 

[ at (interface [i] .pa, *nq[i] (j ,a)) 

-> at (interface [i] .pa.enqd] (j ,a)) 1 

b“*a implies not *at (interface [i] .pa, enq[i] (j ,b)) 

end unreliablequeue 
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It is now possible to make use of the specification of the reliable queue 
to define the service provided by the Alternating Bit protocol. 


datatypes: nodal* 

exporting id.data.meeeage, packet 
theory 

id: typ* 

data: typ* 

packettype : typ* 

n***ag*, ack: packettype 

n*a*ag«: typ* i* tuple [id, data] 

packet: typ* is tnpl*[ packet type, data, boolean] 

•ad datatype* 

ab**rvice: dietribnted modal* 

asing reliablequeue, datatype* 
exporting eerviceinterf ace 

theory 

s*rvic*int*rfac*: modal* [ i: id ] 
exporting pa, pb, sand, r*c 
theory 

pa, pb: external proceea 
•end: operation [ id, data -> ] 
rec: operation [ **> meeeage ] 

end serviceinterlace 

rq: nodale ie new reliableqaeae [id, meeeage] 
j: var id 

il: linkage aerviceinterface[j] .pa - rq.interface[j] .pa 

and eerviceinterfacetj] .pb * rq.interface[j] .pb 

i2: linkage eerviceinterfacetj] .aend ■ rq.interface[j] . enq 

i3: linkage serviceinterf ace[ j] .rec ■ rq. interface [j] .dq 

end abeervice 


The service interface is provided by an inner module serviceinterf ace 
that is parameterized by the identity of the user to whom service is pro- 
vided. The semantics of serviceinterf ace are provided by linking it to a 
copy of reliablequeue for which semantics have already been defined. A 
private copy of reliablequeue, indicated by the keyword new is necessary, 
since we intend only to equate the operation send to enq and not to some 
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other operation that might have been elsewhere also defined in terms of 
reliablequeue. 

Similarly, we define the service specification of the transmission medium 
using the specification of the unreliable queue. 


transmissionserYice: distributed module [ packettype: type ] 
using unreliablequene, datatypes 
exporting transude sionint erf ace 

theory 

transmissioninterface: module [ i: id ] 
exporting pa, pb, send, rec 
theory 

pa, pb: external process 
send: operation C id, packettype -> ] 
rec: operation [ -> tuple [id, packettype] ] 

end transmit tionintarf ace 

unrq: module is new unreliablequene [id, packettype] 
j: var id 

ii: linkage transmissioninterface[j] .pa * unrq[j] .pa 

and transmissioninterface [j] .pb * unrq[j].pb 

12: linkage transmissloninterfaceCj] .transmit - unrq[j].enq 

13: linkage transmis si oninterface[j] .receive » unrq[j] .dq 

end transmissionservice 
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6.3 The Protocol Specification 


We must now define the protocol itself, in the form of local specifications for 
the Sender and Receiver modules. Consider what requirements one would 
like to impose on the visible behavior of the Sender process as part of a 
protocol standard. We will assume the following requirements are desired: 

1. Successive messages must be transmitted in packets having alternat- 
ing sequence numbers. 

2. The sequence of distinct packets transmitted must follow the sequence 
of messages dequeued. 

3. Having initiated transmission of a packet containing a new message, 
only that message may be transmitted until the first uncorrupted 
acknowledgment with the transmitted sequence number is received. 

4. Having initiated transmission of a message, continued retransmission 
must occur at least until an acknowledgment is received. 

5. If acknowledgments for the last transmitted packet are repeatedly 
received, they must lead to a call to dequeue another message. Any 
finite number of acknowledgments may be ignored. 

6. No packet may be transmitted during a dequeue. (By (5), the ac- 
knowledgment for the last packet must have been noted, prior to the 
call of dequeue, with the next message not yet available.) 

The requirements we assume for the visible behavior of the Receiver 
process axe complicated by the need to handle simultaneously messages 
from many sources. In effect, messages from distinct sources axe handled 
independently, as follows: 

1. Until the next packet from a source is received, acknowledgments may 
be transmitted to that source only for the last packet received from 
it. 
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2. If packets are received repeatedly, they must eventually be acknowl- 
edged. Any finite number of packets may be ignored. 

3. In accordance with the Sender requirement that successive messages 
be transmitted in packets with alternating sequence numbers, the Re- 
ceiver can deliver successive messages from a source only from packets 
with alternating sequence numbers. 

4. Only messages from received packets are allowed to be delivered. 

5. The message contained in a packet must be delivered before a packet 
from the same source with a different sequence number can be ac- 
knowledged. Note that this allows the Receiver process to store the 
packets temporarily, since the delivery can occur after the reception 
of a new packet. 

6. Having initiated acknowledgment of a packet, the contained message 
must eventually be delivered. 

In the specification for the Sender module, the first axiom, si, states 
that the module will try to dequeue a message, that no transmissions occur 
before the first dequeue and that, at the time of the first dequeue, the value 
of the expected sequence number has been set to an initial value. 

Rather than use interval expressions to establish temporally the al- 
ternation of outgoing sequence numbers, we introduce state component 
expected, indicating the expected sequence number. This simplifies our 
temporal expressions while not overly constraining implementation strat- 
egy. Note that the value of expected is specified only at the time of returns 
from Dq. 
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sender: module 

using datatypes 

exporting p, dq, transmit, receive 

theory 

p: process 

dq: external operation [ -> message ] 
transmit: external operation [ id, packet ~> ] 
receive: external operation [ -> tuple [id, packet] ] 

i, j: var id 

m, n: var data 

n, v: var boolean 

initial: boolean 

expected : state [boolean] 

si: axiom 

[ -> *at(p,dq) ] not *at(p, transmit) 
and [ after (p,dq) -> ] expected ■ initial 

s2: axiom 

[ after (p,dql <l,m>) -> ] 
expected * not v 

implies [ after (p,dq) -> ] expected * v 

and [ -> at (p, dq) ] *after(p .receive I (i ,<ack,m ( v>)) 
and henceforth 

at (p , transmit ( j , <message , n , u>) ) 
implies i*j and m*n and u*v 

s3: axiom 

[ after (p,dql<i,m> -> ] 
expected * not v 

Implies ( henceforth *af ter (receive (i,<ack,m, v>)) 
implies *at(p,dq) ) 
and ( not *at(p,dq) 

implies henceforth *at (p, transmit (i, <message,m, v>))) 

s4: axiom 

henceforth not ( in(p,dq) and in (p, transmit (i , <message,m,v>)) ) 
end sender 
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The three clauses in axiom s2 express the basic safety requirements on 
the Sender. In clause order, they are: 

• After returning from dequeuing a message m with the currently ex- 
pected sequence number not v, the expected sequence number will 
be v at the time of the next dequeue. 

• At least one uncorrupted acknowledgment with the expected sequence 
number not not v must be received from the destination of the 
message before the next message can be dequeued. 

• Until the next message is dequeued, only <message, m, v> packets 
may be transmitted, and only to the destination of the message. 

Graphically: 


*af ter (p, receive! (i,<ack,m,v>)) 
henceforth at (p, transmit (1 ,<message ,n,u>) ) 

[ implies i=j and m=n and v=u | 

expected=not v expected=v 





v| 



after(p,dq(<i ,m>)) after(p.dq) 

at (p.dq) 

The two clauses of axiom s3 express Sender liveness requirements. After 
returning from dequeuing a message m, with current sequence number not 
v, repeated acknowledgments for sequence number v from the destination 
of the message must lead to a request for another message from the queue. 

Furthermore, that the Sender never attempts to dequeue another message 
implies continual retransmission of the current packet <message , m, v> to 
the destination of the message. 

Axiom s4 expresses a further safety requirement: while the Sender is 
dequeuing another message, no message packet can be transmitted. 

Turning now to the specification of the Receiver module, we again in- 
troduce a state component expected, now a function of the source of the 
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message, defining the current sequence number only at the time of a call 
on Enq. Axiom rl states that the receiver must attempt to receive packets 
and that, until receipt of an initial packet, there will be no prior delivery 
of messages nor transmission of acknowledgments, while axiom r2 requires 
that, for every message received, transmission of an acknowledgment for 
that message implies that the message will be delivered. 

Axiom r3 expresses a safety property about acknowledgments: acknowl- 
edgments will be sent to another destination only for the packet most re- 
cently received from that destination 

_ at (p, receive ! (i ,<message ,n,u>) 
j implies not i a j j 


h 1 

after (p , receive ! <i , <message ,a , v» at (p , transmit ( i , <ack , m , v>) ) 

Axiom r4 expresses a liveness property about acknowledgments: If pack- 
ets are received continually, they must eventually be acknowledged. 
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receiver: module 
using datatypes 

exporting p, dq, transmit, receive 

theory 

p: process 

enq: external operation [ tuple [id .data] -> ] 

transmit: external operation [ id, tuple [data, boolean] -> ] 

receive: external operation [ -> tuple [ id, tuple [data, boolean] ] ] 

i, j: var id 
m, mu, n: var data 
u, v, v: var boolean 

expected: state[function[id->boolean] ] 

rl : axiom 

[ -> ( *at(p, receive) -> after (p, receive I <1, <message, m,v>>) ) ] 
not *at(p,transmit(i,<ack,m, v>) 

and 

[ -> after (p, receive! <i,<message,m, not v») 

or afterCp.recelveXi, <message,m ( v>>) ] not *at(p,enq(<i,m>)) 


r2: axiom 

[ afterCp, receive !<i,<message,m,v») -> ] 

*at(p, transmit (i, <ack,m,v>) implies *at(p,enq(<i,m>)) 

r3: axiom 

[ *af ter (p, receive ! <i , <massage,m,v>>) <- at(p, transmit (i ,<ack,m,v>) ] 
*af ter (p, receive !<j ,<message,n,u>>) implies not i*j 

r4: axiom 

henceforth *af ter (p, receive! <i,<meesage,m,v>>) 
implies *at(p, transmit (i l <ack,m,v>)) 

rS: axiom 

[ at(p,enq(<i,n>)) and expected * not v -> ] 

[ -> at (p, enq: (<i,m>)) ] *after(p, receive I <i, <message,m,v») 
and [ afterCp .receive I <i , <message,m, v>>) 

-> at (p, transmit (i,<ack, mm, not v>) ] *at(p,enq(<i,n>)) 
and [ -> before at(p,enq(<i,m>)) ] *at (p, enq(<j ,nm>) implies not i»j 
implies [ at(p, enq(<i,m>)) -> ] expected ■ v 

end receiver 
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Axiom r5 expresses safety properties related to message receipt. The 
interval logic formula combines these requirements in order to exhibit their 
dependence on a common context. In clause order, their contribution is as 
follows. 

• Delivery of a message must be preceded by its receipt. 

• Having received a packet, the contained message must be delivered 
before an acknowledgment for a packet from the same source with a 
different sequence number is transmitted. 

• Delivery of successive messages from the same source must result from 
packets with alternating sequence numbers v and not v. 
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We can now put the preceding modules together to form the full im- 
plementation specification for the Alternating Bit Protocol. The module 
abprotocol is defined to be a distributed module, since it provides service 
at many sites. In contrast, each user interface is provided by an instance 
of the generic module abinterf ace which should be local since it provides 
service at only a single site. 

The interface module is built from copies of a simple queue qa and 
the sender module to provide the transmission function, and from copies 
of the receiver module and a simple queue qb for reception. Linkages 
make the required connections between their processes and interfaces. 

Communication between interface modules is provided by a copy of the 
transmissionservice module which, of course, is a distributed module. 
Again, linkages make the required connections. 
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ab protocol: distributsd modulo 

using datatypes, simplequeus, sender, rscsivsr, trsnsmissionssrvics 
exporting interface 

theory 

ts: distributsd modulo is nsv transmissionssrvics[packst] 

abintsrfacs: local moduls[ i: id ] 

using datatypes, simplequeus, ssndsr, rscsivsr, transaissionssrvics 
exporting pa, pb, ssnd, rsc, 

s. transmit, s. receive, r. transmit, r.rscsivs, s.p, r.p 

thsory 

pa, pb: external procsss 
ssnd: opsration[ id, data -> ] 
rsc: opsrationC -> mss sags ] 

qa: moduls is nsv s imp lequeue [message] 
qb: moduls is nsv s imp lsqusus [mss sags] 
s: moduls is nsv ssndsr 
r: moduls is nsv rscsivsr 

i: var id d: var data 

il: linkage qa.pa ■ abintsrfacs. pa and qa.pb * s.p 

and qb.pa ■ r.p and qb.pb * abintsrfacs.pb 

12: linkage abintsrfacs. ssnd(i,d) * qa. snq(<i ,d>) 
and abintsrfacs. rsc * qb.dq 

i3: linkage qa.dq * ssndsr. dq and rscsivsr. snq * qb.snq 
snd abintsrfacs 
j : var id 

i4: linkago s[j].p * ts . transmissionlntsrf ace [ j ] . pa 

and r[j].p * ts . transmissionlntsrf ace[j] .pb 

15: linkags s[j] .transmit * ts. transmissionlntsrf aca[j] .send 

and s[j].rscsivs * ts. transmissionintsrfacs [j] .rsc 

16: linkags r[j] . transmit * ts. transmissionlntsrf acs[j] . ssnd 

and r[j]. receive * ts. transmissionintsrfacs [j] .rsc 

snd abprotocol 
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6.4 Conclusions 


This report has described several extensions to Interval Logic and to the 
Revised Special specification language that allow them to specify real-time 
distributed systems. 

As demonstrated by the protocol example, the hierarchical composition 
mechanisms appear to work quite well. However, no hierarchical proof has 
been performed and such a proof is necessary to demonstrate that it is 
possible to maintain separation between levels even during the proof. 

The introduction of processes into the interval logic is adequate. The 
mechanism does what is necessary but is not really very elegant. It would 
have been preferable to be able to rely more on context to define the pro- 
cesses implied by the specifications, but it is unlikely that any purely lexical 
mechanism will suffice to deduce the intent of the designers unless the pro- 
cesses are cited explicitly. 

The extensions to Revised Special appear to be relatively clean and 
easy to implement. It would be preferable to use the special symbols □ 
and O instead of henceforth and eventually. But, even on equipment 
that is capable of displaying the special symbols, their presence in the text 
of specifications would surely cause great difficulty with the editor. 

The extensions necessary to introduce real time constraints into the 
interval logic specifications appear to work well. The extension is clean 
and does not complicate the deduction process. 

Quite a lot of work, much of it software engineering, is still required 
to provide a version of Enhanced HDM that can reason with interval logic 
about distributed systems. Most of that work lies in the area of the decision 
process and in the area of the skolemization procedures that instantiate ex- 
istentially quantified formulae and reduce them to the unquantified ground 
formulae that the decision procedures cam solve. In particular, the prob- 
lem of existential instantiation in quantified temporal logic formulae is still 
unsolved. For specifications in the first order predicate calculus, the 
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instantiation for an existentially variable can be regarded as a constant, and 
it is not difficult for the user to devise a suitable constant. Unfortunately, 
in a temporal logic formula, the appropriate instantiation is a function of 
its temporal context and may be hard for the user to define. We are still 
considering this problem. 
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